ETO Development Tools 4/ETO Development Tools 4.iso/Essentials/MacApp Documentation/MacApp.TECH$ Archives/1991/Feb 91/MacApp.Tech$ 2⁄1⁄91/2826-Using MacApp-Jan91

Text File | 1991-03-06 | 10.6 KB | 185 lines | [TEXT/GEOL]

Item    1929695                         30-Jan-91        17:30PST

From:   ABI.FC                          Applied BioSystems, Foster City,VAR

To:     MACAPP.TECH$                    MacApp Technical

------------------------------------------------------------------------------

Sub:    Using MacApp

Fellow MacApp’ers:

I’ve been seeing some comments on what it is like to be using MacApp and
thought I would throw in my own two bits on the subject.

First off, if you are reading this, you have already solved one major problem.
MacApp.Tech$ is the best resource for MacApp developers that I am aware of.
The quality of the discussions and the commitment of the participants are
exemplary.  Thanks very much to all of you-- those who give their time to
answer questions and those who come up with great questions to ask.  It’s been
a huge help.

Overall, I’d say that using MacApp is very demanding and difficult, but worth
it if you can afford the additional costs.  There are startup costs for
hardware, software, and training, additional personnel costs, and costs
associated with changes in software engineering methodology.  Benefits are
primarily in product quality and life cycle costs.

The hardware and software costs for using MacApp are substantial.  A reasonable
system for MacApp development, especially if you are using C++, is a Mac IIfx
with 8 MB of RAM, a fast 160 MB hard disk, a 13” RGB monitor AND a two page
display.  You’ll also need a CD ROM player, the Developer CD, the ETO CD, the
System 7 CD, a low end Mac for testing, and a variety of printers (for
development and testing).  If this is going to be a multi-programmer project,
you’ll want an E-mail server, an AppleShare file server (for your Projector
DB), Ethernet, and a bridge to LocalTalk (don’t try putting a software bridge
on your file server).

I can’t emphasize enough how important it is to have the fastest hardware you
can get.  If you have already been doing Mac development, you’ll find build
times on a MacApp project to be at least four times longer.  Compiling is
significantly slower, because of the large MacApp header files (even with
load/dump), but the biggest problem is the linker, because it is not
incremental.  The long link times mean you are doing batch instead of
interactive development.  Faster hardware doesn’t change this, but it does make
the turn-around times tolerable, so that programmers will stay at their desks
instead of roaming the hallways while MABuild is doing its thing.

Training and getting up to speed on MacApp is hard.  Not all programmers are
suited for or will be interested in MacApp, hackers especially.  Mac
programming experience is necessary.  You don’t have to be a toolbox wizard,
but a good general understanding is important, and it is essential to have a
solid grounding in human interface design as practiced on the Mac.  The reason
is that MacApp has several complicated hacks (such as view resources) that work
around toolbox problems in order to support the standard Mac human interface.
If you don’t understand or agree with the Mac human interface standards, you
will have a really hard time understanding what MacApp is trying to do in the
first place, and why, not to mention how.  In other words, putting a good PC or
Unix programmer on a MacApp project may be very frustrating and you should
allow a lot of extra time for them to become familiar with various Mac
applications, MPW, and the toolbox.  It is also very helpful for the
programmers to have experience with large systems (>50K loc), software design,
and the basic concepts of object design and programming.  Many of the features
of Object Pascal and C++ are there to solve the problems of programming in the
large.  To use the features of object programming effectively, you have to
understand why they’re there.

The MacApp class at Developer U provides only a very brief introduction.  When
I took the class, the first day was devoted to explaining why we wanted to use
MacApp in the first place.  The second day covered the basic tools, such as
MPW.  This sounds like a waste of time, but there were people in the class who
really needed it.  This left three days to actually cover MacApp.  It was not
possible to get into any aspect of MacApp in depth, or to work on any
non-trivial programming problems.  The class did give a good overview of the
capabilities of MacApp, and I think it worked very well as a confidence
booster.  People who have taken the class tend to come out at a high enough
speed that they have a good chance of breaking through the wall of MacApp
documentation and source code.

I hate to say it but the MacApp documentation is not very good.  It is
especially disappointing when compared with Inside Mac.  The Introduction to
MacApp and Object Oriented Programming is nicely written but is not useful
after the first reading.  The MacApp General Reference has been rewritten to be
almost the same as the Introduction and is not very useful.  The old Release
Notes that were replaced by the General Reference can be useful when you want
to understand a specific class or method.  I guess the Class and Method
Reference HyperCard stacks and 411 help files now have all that stuff but it
was easier to deal with in the printed format where you can look at more than
one method at a time.  The Cookbook is helpful for figuring out where to start
and what’s important when you need to do something.  It won’t tell you
everything you need, but still is the most useful of all the manuals.  Dave
Wilson’s book, Programming with MacApp, is essentially equivalent to the
Developer U class, and I would recommend it for anyone who can’t take the
class.  In the end, you will have to learn the MacApp source code.  The
documentation doesn’t go far enough.  Use Mouser for searching.  Use the
FindTag tool (off the Developer CD) for browsing in MPW without Mouser’s tunnel
vision user interface.  The sooner you get into the source, the faster you will
be up to speed.

While Mouser (MacBrowse) is useful, I have found ViewEdit to be virtually
useless.  I have seen more problems where someone, who doesn’t know better,
assumes that ViewEdit works the way it really should, and ends up totally
frustrated and confused.  ViewEdit does not work with custom view types and is
not suitable for views with lots of subviews or subviews that overlap each
other.  It is poor for controlling the precise size, location, or alignment of
views.  It should be at least as good as ResEdit and MacDraw, but it is not.
Use Rez and DeView.

When programmers first start working with MacApp, there is something it seems
they always have to get out of their system, so plan for it and just do it.
Trace the main event loop and draw a call tree, so you can prove to yourself
that views really do get updated and that mouse clicks, key downs, and menu
choices really are handled.

There’s a great temptation to learn MacApp by writing a throw-away program.
I’m not sure, but my gut feeling is that you have to dive in and start solving
real problems to really learn, and anything else is valuable only as a
confidence building exercise.  Eventually you have to leave the small and
familiar and go into the big unknown.

Once your programmers are up to speed on MacApp, they are worth more.  The job
market for MacApp programmers is competitive.  It is difficult to hire them and
easy to lose them if you train your own.  Expect to have to give them raises
and be nice to them.

Object programming encourages you to work on programs a small piece at a time.
This is good because you get better modularity, once each piece is working it
tends to stay working, and you are always working on a program that works.  A
danger is you can endlessly polish a feature when you should be moving on to
the next one.  You also need to allow time to review specs and do a mini-design
for each piece (class or unit) when you start on it.

MacApp makes it very easy to get a view up and displaying data.  When you have
that, you are not half way done; you have just started.  The second 90% is
writing operators and commands for changing the data, with a third 90% is for
fine tuning.

An important part of object oriented programming is creating classes for your
data.  Since data classes are application specific, MacApp is not going to
provide much that you can use (except for TDynamicArray and TAssociation).  Try
to design each data class as an abstract data type with a fully orthogonal set
of operators.  Don’t skip on operators, you will need them all.  See TList as a
good example.  Be sure to allow time for design and testing of each data class.

Plan to dedicate time and resources for system and configuration management.
It can easily take a day to install MPW and MacApp on a workstation.  Also,
MacApp is rapidly mutating.  The MacApp Engineering group places an emphasis on
developing new features, MacDTS on bug fixes and workarounds.  Testing and
consolidating the different versions of MacApp into a single release is falling
further behind.  I can guarantee that you will not want to use MacApp as it
comes out of the box, but will want to apply your own or somebody else’s fixes
or enhancements.  This means that much comparison, merging, and distribution of
source files is in your future.

When you are done, you won’t have saved much time, but you will have a product
that is much better than you may have expected.  The human interface will be
much closer to the Mac standards.  The code will be more modular and reusable
than anything you’ve written before (even if it isn’t easier to understand).
It will run on 100% of the machines that make up 10% of the market.

Going to MacApp is an investment decision.  For the first project there is a
major investment in tools and training.  For every project there is an
investment in writing modular, reusable code, and in testing each piece of code
as it is written.  The return is in the higher value of the product (better
interface), in reduced life-cycle costs for support, maintenance, and upgrades,
and in potential code reuse.  I don’t think MacApp is for everybody, and the
costs of using it should be seriously considered before using it.  Another way
of thinking about it is that MacApp almost forces you to create better quality
software.  That quality, like anything else, has a cost.  Be sure that you
really need the quality and can justify the cost.

Overall, I’m very glad to be using MacApp.  I hope that my comments will help
people use MacApp wisely and possibly that they might lead to further
improvements in MacApp and its tools.


Tom Becker
Applied Biosystems, Inc.
850 Lincoln Centre Drive
Foster City, CA    94404
[phone]
ABIMAIL.FC  put “ATTN: Tom Becker” as the first line of the message.
[e-mail]